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ABSTRACT 


The propagation of bots into a botnet^ and the various 
malicious activities that could be carried out from within a 
tactical network^ poses a significant threat to network 
security and tactical operations. This thesis presents a 
network architecture with the objective of near real-time 
detection of malicious activity and its propagation within a 
data rate (bandwidth) limited environment with periodic 
losses of connectivity without adding significant burden to 
the network. 

A test bed is constructed that makes use of an 
intrusion detection system driven correlation tool^ 
BotHunter^ focused on outbound and inbound connections^ 
rather than solely on inbound connections and a honeynet 
located in a high data rate area of a tactical network. The 
ability of the proposed architecture to identify malicious 
activities is validated when both BotHunter and the Honeynet 
successfully detect a bot infection. 
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EXECUTIVE SUMMARY 


The propagation of bots^ drone computers (processes) 
characterized by a command and control architecture and 
controlled by a bot controller^ into an army of computers^ a 
botnet^ and the various malicious activities that could be 
carried out from within a tactical network poses a 
significant threat to network security and tactical 
operations. 

The objectives of this work are near real-time 
detection of malicious activity and its propagation within a 
data rate (bandwidth) limited environment with periodic 
losses of connectivity without adding significant burden to 
the network. 

This thesis assembles a test bed to emulate part of a 
tactical network architecture with low data rate and 
periodic losses of connectivity. The architecture makes use 
of an intrusion detection system driven correlation tool^ 
BotHunter^ focused on outbound rather than inbound 
connections and a honeynet to validate the BotHunter. 
BotHunter is placed in a position to experience losses in 
connectivity^ as it will observe all inbound network 
traffic^ but will be limited in its visibility of outbound 
traffic by the honeynet's connection limiting rules. The 
honeynet's honeywall is in a position to observe and record 
all network traffic. 

The test bed architecture as a means of detecting 

botnet infections in low data rate tactical networks is 

validated. BotHunter continued to detect the bot infection 

after the periodic loss of connections caused by the 

xiii 



honeynet. The BotHunter detected bot infection that 
initially attempts to propagate prior to establishing 
command and control^ a behavior that makes it particularly 
hazardous to tactical networks. The origination of the bot 
secondary infection and its malicious action of performing a 
Class B network scan were detected within a matter of 
minutes of the infection on a network limited to a bandwidth 
of 180 kbps. 

Traffic analysis of all packets captured by the 
honeywall allowed determination of the network cost in terms 
of malicious traffic generated in the test bed by the single 
bot infection. The traffic cost for the bot infection 
captured in this work was measured to be 112 Bytes per 
second. 

The requirement for positioning of a honeynet or 
honeynets within the test bed network architecture is 
validated by BotHunter's failure to capture all of the bot 
behavior^ such as the attacking IP address. 

While the concept was validated^ three modifications 
are recommended for future work. A malware collection tool 
should be implemented in conjunction with BotHunter to 
enable collection^ reporting and analysis. Placement of an 
instance of BotHunter between separate honeynets^ without 
direct connectivity outside of the network^ will test its 
effectiveness in internal bot propagation detection. 
Implementation of a honeynet that includes multiple 
instances of exactly the same operating system version will 
enable better observation of botnet propagation as it is 
likely to occur in a tactical network. 
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I. INTRODUCTION 


Commercial^ governmental and personal reliance on the 
Internet has reached a point that a vast majority in the 
developed worlds and much of the rest of the worlds is 
interconnected. Almost every long distance call^ banking 
transaction^ as well as national infrastructure^ can be 
adversely affected by losses of Internet connectivity or by 
the malicious acts of individuals^ organizations^ or states 
that use the Internet. One kind of network exploitation is 
a ^''botnet." The use of botnets allow for an individual or 
organization to harness and mass the computing power and 
bandwidth of large numbers of computers. 

A botnet^ a network of robot or drone computers 
(processes) characterized by the presence of a Command and 
Control (C2) channel^ is a form of malicious software 
(malware) that is capable of self-propagation and can be 
controlled by a botmaster [1^2^3^4]^ unbeknownst to the 
computer's owner. Frequently the botmaster will use the 
botnet for such purposes as conducting distributed denial of 
service (DDOS) attacks^ collecting confidential information 
or for financial scams. 

The botnet C2 architecture is the primary means by 
which it is classified [4] and distinguishes it from other 
malware such as viruses or worms. The most prevalent type 
of botnet C2 uses Internet relay chat (IRC) . This is a 
centralized C2 architecture with the bets logging into a 
central IRC channel to receive commands and updates from the 
botmaster; however^ this architecture has a significant 
weakness. It presents a single point of failure. If the 
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IRC server is taken off line^ there is no longer a botnet 
but a number of individual bots without direction. In order 
to increase the survivability and hide the size of their 
botnets^ botmasters have used other C2 architectures such as 


peer-to-peer (P2P) , 

Hypertext 

Transfer 

Protocol (HTTP) 

and 

fast-flux 

networks 

[4]. P2P 

botnets 

come at a cost 

of 

increased 

latency 

in net response to 

commands, loss 

of 


definitive message acknowledgment^ and increased complexity 
[5] . In recent research^ Holz et al. met with some success 
in disrupting the communications of a P2P botnet [6]. Fast- 
flux is a more sophisticated approach to HTTP as a C2 
architecture in an effort to increase the survivability of 
the network. In fast-flux networks^ the botmaster uses a 
fully qualified domain name but rapidly changes the IP 
address the name resolves to by changing the DNS A records^ 
and in some cases the authoritative name service records as 
well [7] . All of the above mentioned methods of C2 are 
further complicated by the use of encryption. 

Bots are further characterized in [8] as Type I or Type 
II. A Type I bot first attempts to self-propagate prior to 
establishing communications with the C2^ whereas the Type II 
does the opposite. 

A. MOTIVATION 

The protection of tactical networks that support the 

warfighter is predominantly reactive in nature^ using 

definition driven IDS and IPS focused on preventing known 

attacks and located at the network perimeter. As well^ they 

rely heavily on antivirus network scans^ definition updates 

and propagation. The results are numerous alerts and alarms 

for information assurance and network administrators to dig 
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through and analyze along with network traffic for signs of 
malicious activity. This leaves the subordinate or remote 
locations that may have rate limited transmission paths and 
limited training and without tools to detect and self 
diagnose a previously undefined botnet infection. An 
infection can propagate throughout the local area network 
and beyond its perimeter to a trusted adjacent unit or 
higher before it ever trips a perimeter security defense 
mechanism. 

Due to most network defense systems being primarily 
focused on intrusion prevention and detection^ there is a 
real question as to the ability to detect an infection that 
has bypassed those perimeter defenses and is either calling 
outbound or propagating within in order to mount some sort 
of attack from within^ such as a DDOS. As of this writing^ 
the author is not aware of any framework or architecture 
fielded that is aimed at supporting the signals or 
communications officer at the ship^ regiment/brigade or 
lower level with detection and collection of malware. 

B. OBJECTIVES 

The overarching goal of this thesis is to assemble an 
architecture that increases the security of tactically 
deployed networks^ enabling the detection of botnets that 
may have evaded the firewall^ and to a lesser extent to 
capture copies of the malware code for reporting and 
analysis. 

The primary objectives are near real-time detection of 
malicious activity and its propagation within a data rate 
(bandwidth) limited environment with periodic losses of 
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connectivity without adding significant burden to the 
network. An additional topic to be explored in preparation 
for follow on research is the capture of malware for 
reporting and analysis. 

The preponderance of intrusion detection system (IDS) 
and antivirus solutions are heavily definition driven with 
some heuristic components [9]. However^ they are still 
reactive in nature^ meaning that new threats may not be 
discovered unless they match a definition of a previously 
known threat. This presents the obvious question of how to 
respond to and stop the next generation of attacks. The 
first step is detection. 

Tactical networks^ or shipborne networks^ are data rate 
limited. While most researchers using honeypots have 
implemented some sort of data rate limiting to mitigate the 
ability of their research computers being used by a 
botmaster to propagate an attack^ this is a specific 
requirement that must be strongly considered in developing 
any network architecture for the study of tactical networks. 

A test bed—defined here as a monitored and controlled 
environment designed to emulate a part or all of an actual 
network—can be used to establish conditions similar to those 
seen in tactical networks in order to facilitate 
understanding. 

If a previously unidentified Type I bot infects the 
network^ such as via a USB device^ it may propagate within 
the local network and not be seen by the firewall or 
antivirus until it has spread extensively through the 
network and attempts a call home. This presents a 
significant problem. 
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In order to effectively combat a new bot variant^ it is 
essential to capture the malware code for further analysis. 
While this is not a primary objective of this thesis^ it is 
explored in this work in preparation for follow on research 
where it may be incorporated. 

C. RELATED WORK 

The body of work is rapidly growing as are the threats. 
The Honeynet Project has developed numerous tools and 
architectures designed for research in botnet tracking [1] 
and collection [9^ 10]^ with Nepenthes [11] capable of 
collecting unknown exploits of old vulnerabilities. 
BotHunter [3] appears to be the first effort to use IDS type 
technology looking at outward traffic^ rather than the 
customary inward^ and using correlation to detect bots. 
BotHunter also allows for collaboration^ with automated 
reporting back to SRI International. From a different 
perspective^ [12] discusses a botnet communication model to 
evade detection by one of the tools used in this thesis^ 
BotHunter^ by grouping bots into local networks and 
subordinating them to a single controller bot within a 
switched network. The controller bot would then be tasked 
to manage the other bots and be the sole point of contact in 
and out of the compromised network. 

All of the above were tested on large data rate 
networks or small stable^ reliable networks. This thesis 
differs from previous research by focusing on bot/botnet 
detection in tactical networks^ characterisized by low data 
rate connections and intermittent connectivity. 
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D. ORGANIZATION 

Chapter II describes the process of creating and 
maintaining a botnet and covers a range of methods for 
detecting and capturing bots and combating botnets. Chapter 
III addresses the test bed design and how it fits into a low 
bandwidth tactical network. The results and analysis follow 
in Chapter IV. Chapter V provides conclusions^ addresses 
the effectiveness of the test bed network architecture and 
offers suggestions for future research. 
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II. OVERVIEW OF BOTNETS 


This chapter begins with the phases of creating and 
maintaining a botnet and follows with an introduction to 
different tools used to detect^ capture and combat botnets. 

A. CREATING AND MAINTAINING A BOTNET 

There are generally four phases of creating and 
maintaining a bot: 1) initial infection^ 2) secondary 
injection^ 3) malicious activities^ and 4) maintenance and 
upgrade [4]. It is quite common for the phases to be spread 
among different bots or groups of bots. 

The initial infection can be accomplished in any of a 
number of methods [4]: 

a) It could be an active exploit^ initiated with some 

level of network enumeration and or vulnerability 
scanning. Upon locating a computer that meets the 

profile of a known vulnerability^ the attacker will 
attempt an exploit tailored to the vulnerability. 

b) While surfing the web^ malware could be 

automatically downloaded. This may or may not 
require the user to actively click on links to 

initiate the malware download. 

c) SPAM/email attachments are cleverly social 

engineered to deceive the user to open an 

attachment^ resulting in automatic download and 
execution of the binary. 
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d) USB autorun. Conficker [13] uses the USB autorun 
for the malicious activities phase to further 
propagate. 

All windows operating systems have specific ports for 
resource sharing—Ports 445/TCP^ 139/TCP^ 137/UDP and 135/TCP 
are discussed in detail in [1]—and these ports are credited 
for being a major mechanism through which bets are spread. 
These resource-sharing ports are trusted ports. Many 
computers are still left exposed to the Internet without a 
firewall^ giving attackers easy access. Even with a 
firewall^ there are other methods by which the attacker can 
gain a foothold in a network. Then^ the bets can propagate 
within the network using the same resource sharing 
vulnerabilities. In addition to these^ several other common 
vulnerabilities and ports are further discussed in [1] and 
will be observed and discussed in later sections. 

The secondary injection^ also known as the egg 
download^ occurs when the full binary for the bot is 
downloaded. It will include all the tools required for the 
bot to continue exploitation and propagation. The egg 
download can come from the same IP address as the initial 
infection or a different IP address. In some cases^ the egg 
download may occur at the same time as the initial 
attack/infection. One example of this would be Conficker^ 
when introduced via a USB device. 

Malicious activities can include further propagation^ 
searching the machine for passwords^ personal information^ 
etc. 

Maintenance and upgrade includes activities such as 
improving or adding to the bet's toolkits^ establishing a 



backdoor^ patching the same vulnerability that allowed the 
original infection in an effort to prevent others from 
gaining control of the bot and changing the communications 
channel. 

The botnets have become modular [1]^ with plug-and-play 
attributes^ and show signs of collaborative effort in their 
design. Conficker was observed in [14] using a Metasploit 
module to spread itself. The SDBot possesses source code 
commenting that indicates multiple authors [5]. 

Bot creators are able to plug in modules to reduce the 
chances of detection with scripts to detect VMware based 
honeypots [1^ 4]. Botmasters may have bots use low numbers 
of interactions reaching out to the controller^ separate the 
infection phase from the other phase by time^ or use long 
sleep or dormant cycles to avoid detection by traffic 
analysis. 

Having described how bots and botnets are developed^ it 
is time to discuss methods for learning more about them and 
combat them. 

B. METHODS OF DETECTING, CAPTURING MALICIOUS CODE AND 

COMBATING BOTNETS 

Methods of detecting and preventing infection from 
botnets have included use of antivirus software, firewalls, 
and Intrusion Detection Systems (IDS). In order to capture 
malicious code and improve the combat of botnets, 
researchers and security experts have progressed to the use 
or incorporation of honeypots and/or correlation tools. 
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1. Use of Antivirus and Firewalls 

Antivirus software and firewalls rely heavily on a 
priori knowledge of the threats. Antivirus solutions scan 
the host for malicious software and remove patch or delete 
it. Firewalls can be preventative—blocking ports^ IP 
addresses^ and previously known attack patterns—but 
essentially they use filters that operate on rule sets^ 
making them reactive in nature. If some knowledge of a 
specific threat is not known^ then they will likely not be 
effective. Another issue with firewalls is that they are 
designed for perimeter security. Once an attacker has 
gotten past the perimeter^ their effectiveness in preventing 
further proliferation within a LAN is almost non-existent. 
Conficker disables antivirus and firewall software and 
prevents the host computer from accessing security update 
Web sites [15]. 

2. Intrusion Detection Systems 

IDS alone generally operate on signature or anomaly 
recognition; however^ IDS predominantly look at inbound 
packet flows for signs of attacks. The IDS may detect and 
signal numerous attacks^ but do not do well at 
discriminating between successful and unsuccessful 
intrusions [3]. The obvious gap in this approach comes from 
infections initiated by user actions or from an infection 
that begins internally and initiates outbound connections 
[3, 15] . 
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3. 


Forensic Analysis of Network Traffic 


Forensic analysis of network traffic can be a lengthy 
process and generally necessitates knowledge of an infection 
to justify the investment. In addition^ it can include the 
use of tools to analyze router statistics. 

4. Honeypots and Honeynets 

A honeypot is defined by Spitzner as ''an information 
system resource whose value lies in unauthorized or illicit 
use of that resource" [16]. A honeynet is defined as a type 
of honeypot^ made up of a network of computers deliberately 
designed to be attacked and closely monitored behind a 
honeywall to capture all network activity. The honeywall is 
a type of firewall that performs a bridging function and is 
designed to permit intrusion^ but limit outbound 
connections. The bridging function decreases the likelihood 
of detection by an attacker by allowing the honeywall to 
receive^ record and drop or forward packets based upon a 
specified rule set without changing the packets [11]. If 
researchers want to tailor the honeynet to receive a 
particular type of attack^ the honeywall can be configured 
to drop or ignore inbound packets that do not meet the 
established criteria. The outbound connection limiting is 
performed by simply having the honeywall drop the packets 
after the recording step. A honeypot or honeynet 
complements a network security plan^ because it provides 
information in one or all of the following scenarios: 

a) A previously unknown attack penetrates the 
firewall and propagates. 
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b) Either a Type I or Type II bot is introduced 
behind the firewall. 

The critical piece in any of these cases is the bots 
propagating at least behind the firewall. Because any 
activity on a honeypot is malicious by nature^ the honeypot 
provides a means of alarm and information collection to 
analyze the infecting malware [1] . The honeynet used in 
this thesis also includes a rootkit^ Sebek^ which is 
installed as a client on the individual honeypots. The 
rootkit hides in the kernel of the honeypot operating system 
(OS )r acting as a keystroke logger and reports activity via 
UDP packets to the Sebek server that resides on the 
honeywall [10^ 11]. Sebek bypasses the TCP/IP stacks going 
directly to the Ethernet card^ to generate the UDP packets. 
This prevents the OS from being aware of the packets being 
sent. As long as every honeypot has Sebek running on it^ it 
is blind to the Sebek packets sent by another Sebek client. 
The Sebek packets are pushed out onto the local area network 
(LAN) and are picked up and recorded by the Sebek server at 
the honeywall [10] . 

Yet another type of honeypot is a low interaction 
honeypot called Nepenthes that is specifically designed to 
acquire executable malware binary for further investigation 
[9] . 


5. Correlation Tools 

The introduction of correlation engines into botnet 
research brought a powerful tool to the effort of detection 
of individual bots and botnets. The challenge for 
commercial and DoD networks is discovering^ retarding or 
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stopping and ultimately preventing a previously unknown 
method of attack. Several research tools including 
BotHunter^ Botsniffer and Botminer attempt the discovery of 
previously known and unknown bots and botnets with the use 
of correlation algorithms [3^ 11 ^ 18], BotHunter uses a 
combination of botnet behaviors but appears to be the first 
that includes outbound traffic in its correlation algorithm 
[3] . Specifically^ BotHunter establishes a correlation model 
that attempts to identify a relationship between intrusion 
alarm log entries based upon detection of bot infection 
characteristics^ including: inbound scanning^ inbound 
exploit^ outbound connections for secondary infection 
download^ outbound attempts to establish command and 
control^ and outbound infection scanning [3], A correlation 
score base upon detection and sequencing together of bot 
infection behavior is generated in order to yield a relative 
confidence level. The confidence level of a bot detection 
increases as the correlation engine is able to sequence 
together more bot intrusion related events. However^ bot 
detection does not require sequencing together or 
observation of all the bot infection characteristics [3]. 

While the BotHunter correlation model includes outbound 
communications patterns^ it stands to reason the model 
should meet with comparable success if the application is 
run at the gateways of subnets of a larger architecture. 
For example^ tactical networks frequently have a firewall 
performing perimeter defense^ but not between trusted 
adjacent units. Infection of a Type I bot^ attempting to 
propagate throughout all IP addresses beginning with the 
same 16 bits (/16 network)^ could potentially thoroughly 

infect the network and adjacent units and may even initiate 
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a DDoS before it ever attempts to communicate through one of 
the firewalls. This leads to the need to consider placement 
of correlation tools like BotHunter between subnets of a LAN 
in order to discover bot activity early. 

This chapter covered the four phases of creating and 
maintaining a bot^ as well as methods of propagating and 
controlling a group of bots to form a botnet. It then 
addressed common approaches to discovery of bots and 
botnets. This leads to the next step of outlining the model 
design for this thesis. 
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III. TEST BED 


This chapter will present a tactical network 
architecture and explain how the proposed test bed is 
intended to represent parts of the tactical network. The 
second section of the chapter will give specific details of 
the test bed implementation. 

A. RELATIONSHIP OF TEST BED TO TACTICAL NETWORK 

ARCHITECTURE 

The test bed in this thesis is built to address each of 
the requirements outlined in Section Chapter I. In some 
cases^ a requirement cannot be fully achieved^ so risk is 
accepted and discussed. The overarching objective is to 
establish an architecture to look at vulnerabilities of what 
tends to be a homogeneous network. The honeypots built for 
the test bed network are comprised of Windows operating 
systems (OS)^ albeit different versions. 

Figure 1 presents a typical network diagram with an 
addition of the honeynet shown in the dashed box. Ideally 
honeypots would be dedicated to IP addresses across the 
architecture and all data redirected and tunneled to a 
central honeynet below the honeywall^ as shown within the 
dashed box in Figure 1. Honeypots called Collapsar and 
Potemkin have been developed by the Honeynet Project to 
implement these types of architectures [9]. Both appear 
unreasonable to implement on a tactical network either in 
terms of a significant bandwidth cost or a coordination 
challenge due to the increased routing complexity. 
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For Collapsar^ packets are sent across a link twice 
before arriving at or leaving a honeypot. in addition^ 
there is an increase to the packet size as the packet has 
headers affixed to it in order to effect tunneling. The 
storm of packets that could follow an infection multiplied 
by two because of the tunneling architecture could 
unintentionally assist the malware in creating a denial of 
service attack. 



Figure 1. Typical Tactical Network Architecture With 
Addition of a Honeynet in the Dashed Box 
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with Potemkin^ each router would require routing leaks 
to be created in order to make the packets destined for IP 
addresses that should be out at the far left of the 
architecture directed to behind the honeywall before they 
ever pass down Link (i) or Link (ii) . While this may be 
detected easily by a traceroute^ the real issue that makes 
this choice undesirable is the complexity of implementation 
and maintenance on a dynamically changing tactical network. 

The test bed network architecture built closely follows 
that of [11] and is depicted in Figure 2. The test bed is 
intended to closely resemble a trusted low bandwidth link 
much like Link (i) or Link (ii) in Figure 1. BotHunter is 
run on what would appear as a production computer in [11] 
and not behind a firewall; however^ this is actually 
intended to allow BotHunter to sniff traffic that might be 
transmitted between trusted subnets. Multiple instances of 
BotHunter could be run on almost any link^ at either end or 
both ends of a long haul transmission path. Likewise^ a 
single instance could be monitored by administrators at 
either or both ends. 
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63 . 205 . 26.77 

BotHunter 

Monitoring 

63 . 205 . 26.90 

63 . 205 . 26.94 



Ubuntu machine 


63.205.26.90 
Win2K SP3 
Sebek 



63.205.26.94 
WinXP SP4 
Sebek 


10.9.8.40 

Honeywall Remote control station with GUI 
Ubuntu 


Figure 2. Test Bed Developed to Emulate the Low Data Rate 
Side of a Tactical Network and Detect bot infections 

(After [11]) 



The test bed architecture built also attempts to 
address the intermittent connectivity by the use of 
connection rate limiting in the Honeywall rules. As it is 
common for a tactical network to have losses of connectivity 
do to relocation or technical problems^ the connection 
limiting performed by the Honeywall will force any bot to 
perform whatever routines it would do in such an instance. 
It will also test whether or not BotHunter is able to 
determine if a bot is still active upon reestablishment of 
network connectivity. Placement of BotHunter along the low 
bandwidth links gives an easily administered system that 
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combines the advantages of an IDS with the correlation 
capability to give a higher probability of detecting and 
alerting to infection by a previously undefined bot. There 
is almost no cost in bandwidth efficiency with the exception 
of Snort updates^ which can be scheduled for off-peak times 
[19] . On the high bandwidth end^ placement of a honeynet 
within the parts of the network with high bandwidth between 
trusted connections gives an advantage of advanced detection 
within more stable areas of the network and allows for more 
complex honeynet design. In these areas of the network^ 
redirecting and tunneling is an option. 

The Internet access from a local Internet service 
provider is rate limited to no more than 180 kbps and not 
firewalled^ as shown in Figure 2. This resembles a tactical 
network in data rate^ but does not resemble a comparable 
load due to the lack of machines^ services and users. Its 
raw exposure to the Internet is an attempt to accommodate 
this lack of load and to resemble the internal activity 
behind a firewall in a homogenous network. If any machine 
succumbs to an attack and is turned into a Type I bot^ 
almost all machines in the network are equally likely to be 
compromised and become a Type I botnet before detection. 
This concern holds regardless of the method of initial 
infection. 

Now that test bed's relationship to a tactical network 
architecture has been explained^ the specifics of the test 
bed implementation will be detailed next. 

B. TEST BED IMPLEMENTATION 

The hardware and software to support the test bed 
pictured in Figure 2^ and as described in the previous 

19 



section^ are outlined in this section. Specific OS and 
software settings are detailed in the Appendix. 

A Linksys Etherfast 10/100 MBps hub (model EFAH08W 
version 2.0) is used to allow monitoring of all traffic in 
and out of the honeynet by both the honeywall and BotHunter. 
The choice of a hub with data collision control was made to 
reduce the loss of packets with a lower cost than a managed 
switch. 

The BotHunter is run on a Dell desktop machine with 2 
Gigbytes of RAM. An instance of BotHunter was installed and 
run on an Ubuntu 8.04 LTS Desktop operating system. The 
BotHunter version 1.0.2 software download [20]^ User's 
manual [21]^ and Graphical User interface manual [22]^ were 
all obtained from SRI international's www.bothunter.net Web 
site. All BotHunter settings are located in the Appendix. 
BotHunter was placed outside of the honeywall in order to 
allow it to get Snort updates and to report to SRI 
international without affecting the honeywall's connection 
limiting functionality. if placed behind the honeywall^ the 
Snort updates and SRI international connections would have 
counted against the total allowed in and out of the 
honeynet. 

The Honeywall is run on a Dell 2650 with 4 Gigabytes of 
RAM^ 2.4 GHz processor^ and three network interface cards 
(NiCs). The Honeywall CDROM^ Edition roo^ was downloaded 
from the Honeynet Project and installed as described in 
[23] . As specified in [23]^ Ethernet Port 0 faces the 
internet and Ethernet Port 1 faces the honeypots in Figure 
2. Ethernet Port 2 is assigned an IP address in order to 
enable it to get Snort updates and to send alert messages 
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and is positioned behind a firewalled Network Address 
Translation (NAT) router in order to add a level of 
protection. A remote control station was also used on a 
Gateway laptop running Ubuntu and connected behind the 
firewalled NAT router. Specific settings are shown in the 
Appendix. 

The Honeypots consist of two Dell desktop systems with 
operating systems (OSs) and Sebek client installed on each. 
The first system is a Dell Dimension 8100 with 512 MB RAM^ 
and 40 GB hard drive. The operating system installed is 
Windows 2000 Professional with service pack 1 (Win2K SPl) . 
The second honeypot is a Dell Dimension 8400 with 512 MB 
RAM^ and 70 GB hard drive. The operating system installed 
is Windows XP with service pack 2. In each case^ the 
systems OSs were installed and network addresses assigned 


prior to 

Sebek 

being installed. 

Sebek 

was 

run 

on 

each 

machine^ 

but never 

saved on the 

machine 

to 

make 

it 

more 

difficult 

for a 

bot 

or bot controller to 

discover 

it. 

All 


specific settings for the honeypots are in the Appendix but 
are modeled closely after [10]. 

A Netgear 6 port 10/100 Mbps dual speed hub^ Model 
DS106^ is used to allow monitoring of all traffic between 
honeypots by the Honeywall. There is a risk of collisions; 
however^ the likelihood of a bot resending or sending 
additional packets and still being detected is good. An 
oversight in the network design is the possibility of 
collisions of Sebek packets with other packets while in 
route to the Sebek server in the honeywall. The Sebek 
packets are UDP based packets and are therefore unreliable. 
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This necessitates a managed switch or hub that can manage 
data collisions in order to avoid losing packets. 

This chapter covered the test bed built for this 
thesis^ the relationship of the test bed to a tactical 
network architecture and the specific software^ operating 
systems and software settings utilized. The test bed design 
was tied to a portion of a tactical network as it 
transitions from high to low bandwidth connections on 
trusted links behind the network firewalls. The risks 
associated with the test bed design were also discussed. 
This leads to the next chapter^ which will cover the 
results. 
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IV. TEST BED IMPLEMENTAION RESULTS 


The intent of this chapter is to provide a proof of 
concept rather than present experimental results. The 
results demonstrate the effectiveness of the model design in 
a live environment. A botnet attack was detected by both 
the Honeynet and the BotHunter^ proving the effectiveness of 
the design. 

This chapter presents the results in four sections. 
Some overall traffic statistics are presented in Section A. 
Section B discusses the results from the honeynet^ 
specifically data as captured by the Honeywall. Given the 
Honeywall captured all packets passing through it^ the 
Honeywall data is used to provide forensic analysis. 
Section C presents the results as seen from BotHunter. 
Section D brings together and discusses the two previous 
sections. Although BotHunter and the Honeywall did not use 
the same time reference^ all times are presented in or will 
include conversions to Coordinated Universal Time (UTC). 

A. TRAFFIC STATISTICS 

This section is intended to give some gross traffic 
statistics collected from the test bed (see Figure 2). It 
will separate the Sebek packets^ as well as point out the 
common ports and connection types used. 

Figure 3 is a screen capture from Ethereal showing the 
time frame of data collection results with the total amount 
of data collected at the top. The bottom half gives traffic 
statistics with Sebek packets and with Sebek packets 
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filtered out in order to give a perspective of the traffic 
without the artificial inflation of traffic generated by 
Sebek. 
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Figure 3. Gross Traffic Statistics With Sebek Packets 

Included on the Left Side and Filtered Out on the Right 


The data 
minutes^ with 
May 21, 2 00 9 

(00:59 on May 
through the 


collection period was over 2 days^ 5 hours^ 26 
the first packet being collected at 11:33 on 
(19:33 UTC) and the last at 16:59 on May 29 
30 UTC)^ 2009. A total sent or received in or 
honeynet with Sebek packets filtered^ as 


indicated under the column labeled Displayed in the bottom 
of Figure 3 was 339^459 packets or 21.7 megabytes. 






Figure 4 is another Ethereal screen capture showing the 
destination ports for packets coming primarily from the 
honeypots with the Sebek packets filtered out. The 
exception is 63.205.26.67^ which is not in the honeynet^ but 
is later noted as an IP address of interest. The boxes 
direct attention to the more significant ports used. 
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Figure 4. Illustration of Significant Protocols and Ports 
Used by the Honeypots (IP Addresses 63.205.26.90 and 
63.205.26.94) and the 63.205.26.67^ Described as an IP 

Address of Interest 


The top center box shows some use of Port 13500/TCP and 

4545/TCP packets and almost 329^000 Port 445/TCP packets. 

This heavy use of Port 445/TCP represents approximately 98 
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percent of total Sebek excluded traffic. If the Port 445 
traffic is eliminated^ the other ports of interest are 
139/TCP, 137/UDP, 138/UDP and Port 135/TCP. This is 
consistent with the findings described in [1], although 
findings from the test bed show a more heavy weighting of 
Port 445/TCP traffic. The box at top of the right column 
shows traffic from 63.205.26.94, with interest in UDP Ports 
137, 138, and 5355. Although 63.205.26.94 does not trigger 
a bot alert, the UDP/5355 traffic does suggest possible 
infection but is inconclusive. 

This section has introduced some network traffic 
statistics and briefly looked at packets and ports used. 
The Honeywall results in the next section will address a 
more detailed examination of packets coming to and from the 
honeynet. 

B. HONEYWALL RESULTS 

The Honeywall's position, illustrated in Figure 2, in 
front of the honeypots and on the hub beside BotHunter 
allowed it to capture all inbound and outbound traffic, as 
well as the traffic between honeypots. The exception would 
be any case where a UDP packet collided with another packet. 
In such an instance, the UDP packet would be lost due to the 
unreliable nature of UDP. The results presented here show 
the initial infection or attack, the egg download and other 
malicious activity. 

The Bot phases, as they were detected and alerted on by 
the Honeywall and BotHunter, are presented in Table 1 for 
reference in this and following sections. The table 
differentiates Honeywall results as alerts generated or 
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discovery by forensic analysis. Time is given in UTC and 
slight variances^ less than two minutes^ between Honeywall 
and BotHunter times should be seen as insignificant. 

1. Initial Infection 

While the Honeywall recorded the initial infection 
packets^ it did not signal an alert. The absence of an 

alert is a function of the Honeywall's purpose. It is 
intended to allow attacks in^ while recording their actions^ 
and to alert on and slow the outbound propagation of 
infections. 

Figure 5 is a Wireshark screen capture marked to 

highlight the first instance of a discrepancy in physical 
address for the WinXP honeypot IP address for the duration 
of that instance. 

Closer inspection of the packets captured shows 
immediately after an Address Resolution Protocol (ARP) 
request to resolve the MAC address for IP address 
63.205.26.90^ the Win2K honeypot^ a TCP request is sent from 
58.169.17.85 to the WinXP honeypot^ IP address 63.205.26.94^ 
with a MAC address of 00:21:9b:79:Id:cl (pictured in Figure 

5 as Dell_7 9: Id: cl) . This MAC address does not belong to 

the WinXP (63.205.26.94) honeypot and is not used by any 
other machine in the Honeynet or Bothunter. 
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Honeywall 
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Time 

(UTC) 


19:08 


19:09 


23:54 


23:54 


23:54 


23:54 


23:55:46 
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Initial infection 

Inbound Scan 


Maintenance 


C2 Traffic 

Peer Coordination 

Attack Preparation 


Declare Bot 


Alert Sent 


Exploit 

Secondary infection 


Egg Download 

Malicious activities 


Outbound Scan 


Forensic Analysis 

58.169.17.85 ARP 

poisoning use 

63.205.26.94 as proxy 
attempted 63.205.26.90 
connect to 

63.205.26.67 
63.205.26.90 buffer 

overflow from 

63.218.98.110 


63.205.26.90 HTTP . exe 63.205.26.90 HTTP 
Sebek captures egg download from .exe download from 
download command 212.95.32.104 212.95.32.104 


Honeywall msg 

outbound connection 63.205.26.90 

limit reached 63.205/16 scan 


Sebek captures 63.205.26.90 bot TCP 
connect to connect with 
ninjawarlord.com ninjawarlord.com 


63.205.26.90 
start outbound 

detected /24 


Honeywall msg 
outbound connection 
limit reached 


23:57:41 | Generated Report 


63.205.26.90 
determined to be 
bot 

report generated, 
63.205.26.90 bot 


Table 1. Phases of Bot Infection of Win2K (63.205.26.90) Honeypot as Identified From 

Honeywall and BotHunter. 
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Figure 5. First Sign of ARP Cache Poisoning or MAC Spoofing Involving Honeypot 

63.205.26.94 and Collected by the Honeywall 
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However^ the MAC address used for the WinXP honeypot is 
different from the actual MAC address of 00:60:08:c5:ff:a8. 
This appears to be a MAC spoofing or ARP cache poisoning. 

A description of ARP cache poisoning and MAC spoofing 
is briefly described below. In the interest of network 
speed and reduced congestion^ the majority of network 
devices maintain a cache of ARP results identifying the 
assignment of a MAC address to a specific IP address. 
Regardless of the IP address assigned to the packets^ the 
MAC address is the next physical destination of the packets 
in its route. ARP cache poisoning is the process of sending 
false information in order to replace or submit false MAC 
addresses for an IP address [24]. MAC spoofing is sending 
packets with a false or created MAC address that is 
different from the actual MAC address of the sending machine 
or receiving machine^ thus allowing the machine to 
impersonate another machine [24]. 

Different from Figure 5^ Figure 6 shows the ARP 
poisoning occurred on several occasions throughout the 
experiment. The first column shows the packet numbers^ and 
the second column gives the time of the occurrence of ARP 
poisoning. 

Figure 6 shows the suspicious flow starting at packet 
number 197. A device masquerading as the WinXP machine with 
IP address 63.205.26.94^ normally MAC address 3com_c5:ff:a8^ 
is sending broadcast messages from MAC address 
Dell_7 9: Id: cl. This use of the MAC address for the WinXP 
honeypot is repeated several times as shown in Figure 6. It 
should be noted the Honeywall is preventing most of these 
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packets from getting out. Therefore^ there will be a large 
volume of connection attempts that go without response. 
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Figure 6. Mac Spoof with packet numbers in first column to illustrate multiple occasions 
spread across the collection period and could be indicative of a communication 

Channel or an attack 
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One possible reason for this is that the machine 
sending is not 63.205.26.94 but instead another machine on 
the LAN subnet is MAC spoofing as 63.205.26.94 in an attempt 
to get past the firewall or to use the MAC address as a 
communications channel. 

Another unusual behavior not shown in Figure 5 or 6 was 
recorded in packet 249 in which 63.205.26.90 initiates a 
connection with 63.205.26.67. Prior to this line^ there is 
no known communication between 63.205.26.67 and the 
honeypots (63.205.26.90 or 63.205.26.94). There is no 
reason for the honeypots to have knowledge of the existence 
of 63.205.26.67. They have both sent multiple broadcasts 
but do not appear to have received any responses from the 
production side of the honeywall (to include 63.205.26.67). 

Figure 7 shows the first clearly observed phase^ the 
initial infection. The initial infection is achieved through 
an exploit of a vulnerability^ which forced a buffer 
overflow. A buffer overflow and initiation of a subsequent 
egg download are captured and shown in Figure 7. The buffer 
overflow exploits a software vulnerability by inputting more 
data than intended to be received and causing the excess 
data to be placed into another buffer. This can lead to an 
attacker gaining access to what would otherwise be 
restricted code or processes on the computer [24]. 

Infection of the Win2K honeypot occurs at approximately 
2357 UTC on May 21 f 2009 (see Figure 7) . The attack 
originates from IP address 63.218.98.110 and is attempted a 
few times before succeeding. 
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Figure 7. Honeywall Packet Captures Showing Initial Attack via Buffer Overflow^ 
Sebek captures on honeypot 63.205.26.90 and Initiation of Egg Download 
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2. Secondary Infection 


Upon success of the buffer overflow^ Sebek captures and 
reports a command for the honeypot to establish an http 
(Port 80) connection with iP address 212.95.32.104. This 
download is an executable named lOx.exe and is shown in 
Figure 7. 

Figure 8 shows the completion of the egg download 
followed by the beginning of the new bot's malicious 
activity. Approximately 6-7 seconds after the download is 
complete^ the honeypot begins what will be a complete Class 
B (63.205/16) scan. 

3. Malicious Activities 

Alerts messages^ not shown in Figure 7^ sent by the 
Honeywall indicate malicious activity in the form of 
multiple outbound connection attempts as early as 2354 UTC 
on May 21^ 2009. The Honeywall also sent an alert 

indicating the maximum number of connection attempts had 
been exceeded. Forensic analysis shows the Win2K honeypot 
at 63.205.26.90 begins a full Class B (63.205/16) network 
enumeration (vulnerability scanning) to include IP addresses 
internal and external to the 63.205.26.65/27 network 
containing the honeynet. Sebek packets^ shown in Figure 8^ 
also indicated a malicious program on the Win2K honeypot 
issuing commands. This confirms the Win2K honeypot is 
infected. 
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4 . 


Maintenance 


Shown in Figure 8^ the new bot performs a DNS query to 
resolve an IP address for ninjawarlord.com and attempts a 
connection with a response from ninjawarlord.com^ a command 
and control channel for the botmaster. 

Not shown in Figure 8^ the bot repeats the DNS query 
every few minutes. In addition^ the bot performs a keep 
alive messages in order to keep a communication channel open 
to IP address 63.218.98.110. After completing the 63.205/16 
network scan^ the bot continues to maintain the keep alive 
messages and to perform the DNS query for ninjawarlord.com. 
The bot does not appear to meet with any success in 
propagating; although^ this could be heavily influenced by 
the honeywall's connection limiting function. 

The packets captured by the honeywall^ covering May 27 
to May 29^ 2009^ give no evidence of further infections. 
However^ there are numerous additional attempts. The bot's 
assignment may be to perform scanning and report to the 
server. 
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No. . 

Time 

Source 

Destination 

Protocol 

Info 




Src MAC 

15/4 

15:54:52.22BU3U 

63.205.26.90 

212.95.32.104 

TCP 

ams > nttp [ACKJ seq=i49 Aci<=65029 win=b4240 

Len=u 

De1icomp_e/:r9: 

1575 

15:54:52.232178 

212.95.32.104 

63.205.26.90 

TCP 

[TCP segment of a reassembled PDO] 




cisco_c9:f6:f4 

1576 

15:54:52.334020 

212.95.32.104 

63.205.26.90 

TCP 

[TCP segment of a reassembled PDU] 




Cisco_c9:f6:f4 

1577 

15:54:52.334284 

63.205.26.90 

212.95.32.104 

TCP 

ams > http [ack] seq=149 Ack=67381 win=64240 

Len=0 

De]]comp_e7:f9: 

1578 

15:54:52.341997 

212.95.32.104 

63.205.26.90 

TCP 

[TCP segment of a reassembled PDU] 




cisco_c9:f6:f4 

1579 

15:54:52.349975 

212.95.32.104 

63.205.26.90 

TCP 

[TCP segment of a reassembled PDU] 




Cisco_c9:f6:f4 

1580 

15:54:52.350240 

63.205.26. 90 

212.95.32.104 

TCP 

ams > http [ACK] seq=149 Ack=70301 Win=64240 

Len=0 

De]]como_e7:f9: 

1581 

15:54:52.357971 

212.95.32.104 

63.205.26.90 

TCP 

[TCP segment of a reassemb]ed PDU] 



Egg Download 

Complete 

1582 

15:54:52.358661 

212.95.32.104 

63.205.26.90 

HTTP 

HTTP/1.1 200 OK (app 1 1 cat! on/x-msdown raaci. 


1583 

15:54:52.358811 

63.205.26. 90 

212.95.32.104 

TCP 

ams > http [ACK] Seq=149 Ack=72065 Win=642^ 


1584 

15: 54:54.508205 

63.205.26. 90 

63.205.26. 2 

SEBEK 

SEBEK - pidC420) uid(O) fd(0) cmd: 





1585 

15:54:54.508303 

63.205.26.90 

63.205.64.23 ◄- 

TCP 

mtqp > microsoft-ds [syn] seq=0 WTn= 

64240 LenM} MSS=1460 

DelTconip e7 :f9: 

1586 

15: 54: 54. 53744 5 

63.205.26. 90 

63. 205. 26. 2: 

SEBEK 

SEBEK - pidC420) uidCO) fdCO) cmd: 





1587 

15:54:54.537586 

63.205.26.90 

63. 205.162.171 

TCP 

sbl > microsoft-ds [syn] seq^ win=6 

DNS 

auerv ninnawariord.com 

1588 

15:54:54.561237 

63.205.26. 90 

63.205.26.2 

SEBEK 

SEBEK - pidC216) uidCO) fdCO) cmd: 






1589 15:54:54.56143Z 

1590 15:54:54.567470 

1591 15:54:54.567599 

1592 15:54:54.575558 

1593 15:54:54.576507 

1594 15:54:54.576603 


1596 15:54: 

1597 15:54: 

1598 15:54: 

1599 15:54: 

1600 15:54: 

1601 15:54: 

1603 15:54 

1604 15:54: 

1605 15:54: 

1606 15:54: 


54.597538 

54.597617 

54.627534 

54.627608 

54.657559 

54.657676 

54.687623 

54.687731 
54.717705 
54.717818 


63.205.26.90 

63.205.26.90 

63.205.26.90 

206.13.28.12 
63.205.26.90 

63.205.26.90 

63.205.26.90 
63.205.26.90 
63.20 5.26.90 
63.205.26.90 
63.205.26.90 
63.205.26.90 

63.205.26.90 

63.205.26.90 

63.205.26.90 
63.205.26.90 


206.13.28.12 

63.205.26.2 

63. 205.4. 64 

63.205.26.90 
63.205.26.2 

75.146.106.2 01 

63.205.26.2 
63.205.102.213 
63.205.26.2 
63.205.200.105 
63.205.26.2 
63.205.42.25 4 

63.205.26.2 

63.205.140.146 

63.205.26.2 

63.205.238. 38 


DNS 

SEBEK 

TICP 

DNS 

SEBEK 

TICP 

SEBEK 

TCP 

SEBEK 

TCP 

SEBEK 

TCP 


Standard query A ninjawarlord.com 
SEBEK - pidC420) uidCO) fdCO) cmd: 

danf-ak2 > microsoft-ds [SYN] seq=0 Win=64240 Len^ MSS=1460 

Standard query response A 75.146.106.201 A 221.143.48.246^- 

SEBEK - pid(420) uidCO) fd(0) cmd: 

afrog > worlds cores [SYN] Seq=^ Win=64240 LenMJ MSS=1460^ 

SEBEK - p1dC420) uidCO) fdCO) cmd: 

boinc-client > microsoft-ds [syn] seq=0 win=64240 Len=^ MS 
SEBEK - pidC420) UidCO) fd(0) cmd: 

dcutility > mfcrosoft-ds [syn] seq=0 Win=64240 Len^ mss=1j 
SEBEK - pidC420) UidCO) fdCO) cmd 

fpitp > microsoft-ds [syn] seq^ wfn=64240 Len=^ M55=1460 


DNS response 


63.205/16 scan begins 


eq=0 Win=64240 Len^ MS& 
in=64240 LenMJ MSS=1460 


Dencomp_e7 :f9: 


to 


Bot attempt 
contact 

ninjawarlord.com 
and response. 


Figure 8. Honeywall Captured Packets Show Egg Download Completion^ DNS Query and 
Response to Resolve an IP Address for ninjawarlord.com in Order to Establish 
Command and Control^ and Initiation of 63.205/16 Network Scanning 
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The results of performing Wireshark's IPv4 
Conversations function^ shown in Figure 9, on the captured 
packets from May 27 to May 29, 2009 yields some information 

of interest. The goal was to find or confirm infection 
downloads or C2 channels. Figure 9 shows only the two-way 
conversations^ with the exception of Sebek and broadcast 
packets that were left in to give some idea of what would be 
expected in the way of return traffic if the honeywall did 
not limit the rate of outbound packets. The majority of 
packets from the 63.205/16 network scan are one-way and^ 
therefore^ eliminated from the figure. In some cases^ a 
download or conversation could be one-way and would be 
overlooked. Conversations are loosely defined as a packet 
sent to a destination and a packet received from that 
destination. Some conversations are failed attempts of 
establishing a connection^ whether it be for an exploit^ egg 
download or C2 channel. 

5. Honeywall Analysis 

Due to possibly encrypted channels^ the author draws 

the conclusion that conversations between the confirmed bot 

(63.205.26.90) and IP addresses outside of the honeynet 

subnet are possibly efforts by the bot to check into C2 

channels. The expectation for a C2 channel is a relatively 

low number of outbound (bot initiated) keep alive messages 

or some other packets sent periodically^ spanning a large 

period of time. Due to the outbound connection rate 

limitation of the honeywall^ a smaller number of responses 

would be expected than the number of outbound attempts. 

Shown in Figure 9, conversations that appear to meet this C2 

channel description are between: a) 63.205.26.90 and 
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63.218.98.110^ with 465 packets exchanged in 7 hours (66.4 
packets per hour (pph))^ b) 63.205.26.90 and 118.123.5.109 
with 87 packets across a 19.4 hour period (4.5 pph)^ and c) 
63.205.26.90 attempted connections to ninjawarlord.com which 
DNS query resolves to IP addresses 221.143.48.246 and 
75.146.106.201 as previously shown in Figure 8. 

Vulnerability scanning or attacks could be 
characterized by either a barrage of different inbound 
connections in search of the correct input to trigger a 
desired response such as a buffer overflow^ or periodic 
inbound unsolicited packets in an attempt to stay below any 
detection thresholds. This appears to be the case with 
inbound connection attempts between 121.15.245.215 and 
63.205.26.90^ with 6 packets exchanged during 18.7 hours 
(0.32 pph). 

An egg download would be characterized by a large 
amount of data transferred in a short period of time and 
possibly with large packet sizes. An attempt at a buffer 
overflow could also be characterized by large packets being 
sent. If there are multiple attempts at the buffer overflow 
over a long period of time^ it could appear similar to an 
egg download. An example is shown in Figure 9 by the 
63.205.26.90 to 212.95.32.104 conversation^ which has 
already been identified as an egg download. In this 
instance^ a download of approximately 6390 bytes is carried 
out in a conversation that lasts less than 12 seconds. 
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Figure 9. Results of Wireshark's Conversations Function Performed on All Packets Captured 
Limited to a Minimum of 4 Packets Per Conversation for Inclusion with Sebek Packets 

and Standard DNS Queries Blocked Out 
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The downloaded packets were reassembled using Wireshark 
and submitted to Symantec Corporation's online malware 
evaluation ( https ://submit.Symantec.com/websubmit/retail. cgi ) 
system to determine if it is a previously known threat. 
When scanned by Symantec Anti-Virus software^ the file is 
determined to be the W32.Randex worm. 

This section of the results looked at packets captured 
by the honeywall primarily down to the traffic level. it 
showed the attack^ egg download and the new bot's network 
scanning. The next section will look at BotHunter's 
results. 

C. BOTHUNTER RESULTS 

This section presents the results of BotHunter and 
discusses the bot findings. The reader should recall that 
BotHunter is run in front of the Honeywall and not behind a 
firewall. in addition^ a correlation score based upon the 
detection sequencing together of bot infection behavior is 
generated in order to render a relative confidence level. A 
score between 0.8 and 3.8 is required to trigger a bot 
declaration^ with a higher correlation score indicating 
greater confidence [22]. 

Figure 10 presents a screen shot of the BotHunter GUi^ 
with multiple declared bots listed under ^'Victim IP." The 
bots are sorted in order of correlation scores and not with 
respect to when they were declared^ labeled as ^'Gen time." 

The Bothunter indicated its first bot detection at 

approximately 2357 UTC on May 21, 2009 on the Win2K (IP 

63.205.26.90) honeypot (see Figure 2). The Bot declaration 

was based upon detection of a HTTP based executable download 
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(egg download) and subsequent outbound scanning of first 10 
and then 21 IP addresses in a /24 network within 5-7 seconds 
of the egg dowload. This does not contradict the Honeywall 
results above^ rather it shows BotHunter's sensitivity is 
high enough that it triggered a bot detection before the 
scanning went beyond the first /24 subnet of the larger 
63.205/16 network. The egg download was detected coming 
from IP address 212.95.32.104 with a correlation score of 
1.8. Information about the inbound network scan or type of 
exploit used to gain access to the 63.205.26.90 honeypot is 
not shown by BotHunter. This is likely due to BotHunter not 
being located behind and firewall. During setup^ BotHunter 
requires a setting to indicate whether or not it is behind a 
firewall. When it is not located behind a firewall^ its 
sensitivity to inbound attacks is decreased. 

The second bot declaration is shown with a correlation 
score of 1.3 but with less information. Not shown in Figure 
10^ this declaration is based exclusively on the detection 
of intense network IP address and port scanning originating 
from the 63.205.26.90 honeypot. 
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Figure 10. 


BotHunter Screen Shot Illustrating Multiple Detections of a Bot on 

63.205.26.90 
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Additional bot detections are declared by Bothunter at 
00:04 UTC on May 28, 2009 and at approximately 6 minute 
intervals thereafter until 00:40 UTC May 28^ 2009. Of note^ 
almost all of the declarations barely meet the 0.80 
correlation score. These additional bot detections do not 
include the egg download or any other information other than 
intense outbound IP address and port scanning. The 
additional bot detections are likely repeat declarations of 
the same bot infection^ given that the subnets (not shown) 
scanned are all within the larger 63.205/16 network. The 
absence of peer coordination or C2 information could be a 
result of channel encryption. 

Albeit briefs this section covered the BotHunter's bot 
detection. The results clearly indicate a single bot 
infection and suggest that the additional declarations are 
due to additional scanning of subnets within the 63.205/16 
network. The next section will combine the results from the 
honeynet and BotHunter. 

D. HONEYNET AND BOTHUNTER RESULTS COMBINED 

This section will focus on the synthesis of an overall 
result^ using a fusion of BotHunter and honeynet results 
from this low data rate network. 

The review of traffic and Sebek packets captured by the 
honeywall did verify the first bot declaration by BotHunter. 
The Sebek packets recovered from the Sebek server on the 
honeywall also identified the egg download command and 
verified the egg source IP^ as reported by BotHunter^ 
immediately following the buffer overflow that was not 
detected by BotHunter. 
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A closer look at the packets captured with the 
honeywall showed a full 63.205/16 network scan with what 
could be multiple attempts at command and control 
connections imbedded within the scanning. Although none 
were detected by BotHunter^ two honeywall results suggested 
the existence of C2 channels. The first suggestion of C2 
channels was shown in the keep alive messages to IP address 
63.218.98.110^ the same IP address that originated the 
successful buffer overflow. As seen in Figure 9^ this 
connection was maintained over a 7 hour period. The second 
suggestion of C2 channels is seen in several other 
conversations^ shown in Figure 9^ to last over a period of 
several hours. Yet another way these C2 channels maybe seen 
is in the 63.205.26.90 honeypot outbound connection attempts 
to IP addresses outside of the 63.205/16 network scan. 

in summary^ this chapter gives honeynet results^ 
followed by BotHunter results and then combines the two for 
a more complete picture. The honeynet traffic shows a cost 
of approximately 100 bytes per second for the bot infection. 
A closer look at the packets captured by the honeynet's 
honeywall shows the attack and subsequent egg download^ 
confirming the egg download and source detected by 
BotHunter. it does not provide any clarity for why 
Bothunter did not detect the attack. The honeynet traffic 
analysis supports the idea that the additional BotHunter 
declarations with low correlation scores are repeated 
detections of the same infection. The need for a honeynet 
within higher bandwidth areas of the tactical network is 
supported by the fact that the honeynet collects all packets 
and enables better analysis than BotHunter. 
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V. 


CONCLUSIONS 


This thesis developed a test bed for the detection of 
botnet infections at the low data rate end of tactical 
networks. The test bed was developed with the use of 
BotHunter and a honeynet. BotHunter is a tool that employs 
a correlation algorithm^ intrusion detection system 
definitions and characteristics of basic botnet behavior. 
The honeynet is included in order to emulate results that 
would be seen in parts of a tactical network that operate at 
higher data rates. The results of the test bed validated 
the effectiveness of BotHunter for botnet detection in low 
bandwidth areas of tactical networks and the usefulness of 
honeynet employment within tactical networks where 
connections with higher data rates exist. 

A. SIGNIFICANT RESULTS 

The most significant result of the test bed is the 
successful validation of the test bed architecture as a 
means of detecting botnet infections in low data rate 
networks such as those found in tactical environments. 
BotHunter continued to detect the bot infection after the 
periodic loss of connections caused by the honeynet's 
connection rate limits. In addition^ BotHunter detected a 
type of bot infection that could be particularly hazardous 
to tactical networks. The origination of the bot secondary 
infection and its malicious action of performing a Class B 
network scan were detected within a matter of minutes. 

Traffic analysis of all packets captured by the 
honeywall allowed determination of the network cost in terms 
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of malicious traffic caused to the test bed by the single 
bot infection. The traffic cost for the particular bot 
infection captured in this thesis was measured to be 112 
Bytes per second. 

The requirement for positioning of a honeynet or 
honeynets within the test bed network architecture is 
validated by BotHunter's failure to capture all of the bot 
behavior^ such as the attacking IP address. The honeynet 
captured all the bot infection phases^ including those not 
seen by BotHunter^ for a previously known bot infection. 
Use of BotHunter does come with some risk of failure to 
detect a previously unseen bot attack technique. Employment 
of a honeynet in the higher data rate areas of a network 
mitigate the risk of a missed bot detection by providing 
depth and greater information. As explained by Spitzner in 
[16]^ activity on a honeypot is by definition suspicious and 
likely to be malicious. 

With a relatively low sensitivity setting^ BotHunter 
successfully detected and reported a bot infection within 
six minutes of the initial infection on a data rate limited 
connection of 180 kbps. BotHunter further provided the 
ability to detect a bot infection without an additional 
traffic cost as seen by use of the rootkit^ Sebek^ with the 
Honeynet. 

B. FUTURE WORK 

Previous research has looked at bot/botnet detection 
within well established high data rate networks; this thesis 
differs from previous research by focusing on 
characteristics of tactical networks. Tactical networks are 
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characterized by low data rate connections and periodic 
losses of connectivity. A progression for future work would 
be to add complexity in a manner that more closely resembles 
a tactical network. 

1. Employ a Honeynet Consisting of a Homogenous 
Network of Honeypots 

The test bed was designed with a non-homogeneous 
honeynet consisting of two honeypots with one of each 
operating system^ Win2K and WinXP. The method of attack in 
the initial infection by a bot is generally based upon a 
specific operating system or other software vulnerability 
that is likely to change between version releases. A 
tactical network would typically have a high degree of 
homogeneity^ with the majority of computers having the same 
operating systems with similar level of updates and 
antiviral signatures. The test bed should be modified to 
include multiple instances of any operating system (and 
other software) versions of interest in order to observe 
propagation of bot infections and more closely resemble a 
tactical network. 

2. Position BotHunter Between Subnets 

The BotHunter was positioned outside of the honeynet 
and was not behind a firewall. Successful propagation of 
the bot is not seen by BotHunter. The new location for 
BotHunter should be behind a firewall and between trusted 
production subnets (with no firewall between them) on a 
tactical network or between separate honeynets. 

This can be done by establishing two honeynets on 

separate subnets under a common /16 network^ both with 
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separate firewalled access to the Internet^ with a non- 
firewalled link between honeynets. Such a network would 
allow for better simulation of a tactical network and to 
further test whether BotHunter could be used as an early 
warning tool at the low data rate end of the network. In 
addition^ multiple bot infections could be deliberately 
introduced behind the honeynets in order to observe bot 
behavior. 

3. Addition of a Malware Collection Tool 

The Honeywall's use of Sebek for collection of malware 
is unreliable because Sebek uses UDP. Without the 

reliability^ collisions^ dropped or missed packets for any 
number of reasons can result in a loss of malware binary. 
In addition^ BotHunter does not provide the capability to 
collect the actual malware code/files. To fix this^ the 
test bed could be modified to include Nepenthes. The reader 
is reminded Nepenthes is a malware collection tool that can 
be setup to collect the malware and pass the malware to a 
central collection point for analysis [9]. 
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APPENDIX. EQUIPMENT AND SOFTWARE SETTINGS 


A. HONEYWALL 

1. Honeywall CDROM Root Install 

root password: !#79RuuB4me 

roo password: Victoryl/5! / !#79RUUBme5 

Note: Port and IP address numbers are separated by 

spaces. Do not include colons, semicolons or commas. 

TCP allowed out (port numbers): 22 25 43 80 443 

UDP allowed out: 53 123 

Connection limiting set to: hour 

TCP limit: 24 UDP limit: 23 

ICMP limit: 57 Other protocols: 14 

Honeypot IPs: 63.205.26.90 63.205.26.94 

CIDR: 63.205.26.64/27 Broadcast: 63.205.26.95 

Management Interface (Walleye) settings 

Management Interface IP: 10.9.8.41 

Mask: 255.255.255.0 Default Gateway: 10.9.8.1 

System host name: localhost domain name: localdomain 
DNS server IPs: 206.13.28.12 206.13.29.12 
Configure SSH: yes 
Let root login remote: no 

Manage intereface allow inbound ports: 443 
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Allow IP to login to management interface: 10.9.8.40 

Web interface for analysis: yes 

Restrict firewall outbound comm: yes 

SNORT_Inline: yes 

Blacklist: (none) 

Whitelist: (none) 

Black/white list filtering enable: Yes 
Disable ''strict" capture filtering: no 

Fencelist location: /etc/fencelist.txt (IP addresses 
and CIDR blocks 

Enable Fencelist filtering: no 
Enable "Roach motel" mode: no 
DNS: unlimited 

Limit Honeypot unlimited access to DNS: no 
Restrict DNS server: no 
Email alerts: yes 

Email address: insert your email address here 

Alert start auto @ : yes 

SEBEK 

Dest IP Sebek packets: 63.205.26.2 

Dest Port: 1101 

Sebek Var: Accept and Log 

Oink Code is needed for Snort. Go to Snort Web site to 
login and request an Oink Code. https://www.snort.org/login 
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B. HONEYPOTS 

1. Windows 2000^ Service Pack 3 

a. Wipe Hard Drive 

First run Hard Drive wiping utility^ such as 
Derik's Boot and Nuke^ from http://dban.org in order to 
clean the hard drive and its boot sectors. 

b. Insert and Run Install of Win2k SP3 

Delete any partitions 
Perform long format 
Computer name: Sam 
Organization: Sam Group 

Product Key: Enter your product key here 
Computer Name: Sam-86ST 
Admin Password: !#79R()CK! 

Choose Typical settings 
Check Workgroup option 

IP: 63.205.26.90 Mask: 255.255.255.224 

Gateway: 63.205.26.65 

DNS: 206.13.28.12 206.13.29.12 

c. Sebek Install 

Run sebek from disk^ so that it is never copied 
onto the hard drive. 

Driver name: Sebek 
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Destination MAC: (MAC Address of NIC 1, inward 
facing NIC of Honeywall) 00:02:B3:CA:D4:EC 

IP: 63.205.26.2 

Port: IIOI 

Magic Value: 3289080092 

Configuration program name: services25v 

Sam's dog Password >flD0! F!dO 

Mutt 

Unregmp2.exe 

Admin Password: !#79R()CK! 

Guest: p@ssing! 

2. Windows XP, Service Pack 2 

a. Wipe Hard Drive 

Perform Hard drive Wipe as in Win2k paragraph l.a. 

b. Insert and Run Install of WinXP SP2 

Delete all partitions 
Perform long format 
Name: Joe 

Organization: Joe Group 
Computer Name: JOE-8F60 
Admin Password: C0rn4@all 
Select Typical settings 
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Select Workgroup 


Static IP: 63:205.26.94 Mask: 255.255.255.224 
Default Gateway: 63.205.26.65 
DNS: 206.13.28.12 206.13.29.12 
Create users: 

Username user type password 

Bobby admin TlghtOss 

Sue limited lLlkeU2 

c. Sebek Install 

Run sebek from disk so that it is never copied 
onto the hard drive. 

Driver name: Sebek 

Destination MAC: (MAC Address of NIC 1, inward 
facing NIC of Honeywall) 00:02:B3:CA:D4:EC 

IP: 63.205.26.2 

Port: 1101 

Magic Value: 3289080092 

Configuration program name: services25v 

C. BOTHUNTER 

Bothunter is installed per the instructions in [21] and 
the graphical user interface (GUI) instructions in [22]. In 
this configuration^ BotHunter is not run behind a firewall^ 
requiring entry into the custom configuration option per 
[ 21 ] . 
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